![[2020年版]最強のAWS環境セキュリティチェック方法を考えてみた[初心者から上級者まで活用できる]](https://devio2023-media.developers.io/wp-content/uploads/2020/10/super_security_check_1200_630.png)
[2020年版]最強のAWS環境セキュリティチェック方法を考えてみた[初心者から上級者まで活用できる]
こんにちは、臼田です。
みなさん、AWS環境のセキュリティチェックしてますか？(挨拶
全国のAWSのセキュリティについて悩んでいるみなさまのために、今回は僕の考える最強のAWS環境セキュリティチェックについて情報をまとめ・伝授します。
初心者向けに、比較的AWSの経験が浅くても始めやすいように、かつ上級者が応用するために活用できる情報もぜんぶまとめていきます。
この記事は2020年の決定版となるでしょう！(それ いいすぎ。
ながーくなってしまったので最初は適宜飛ばして読むといいかもしれません。
AWS環境のセキュリティチェックの意義
AWS環境でセキュリティチェックをすることは様々なメリットがあります。
AWSにおけるセキュリティは責任共有モデルによりわかりやすく責任範囲が説明されています。
利用するAWSサービスの設定値を適切に保つことは利用者の責任となります。
例えばEC2に割り当てるSecurity GroupでSSHを世界中に公開したり機密データを保存したS3バケットを公開してしまったりと直接脅威につながるような設定がされていないか、CloudTrailやGuardDutyなどの必要なセキュリティ機能の有効化などは利用者が気にしなくてはいけません。
どのような設定が好ましくないか、あるいはその設定が適切に維持されているかはセキュリティチェックで確認することが可能です。
今回のセキュリティチェックのスコープ
さて、ここまで説明してきた「セキュリティチェック」という言葉はAWSの設定値を確認するという手法のセキュリティチェックになります。
単にセキュリティチェックと言った場合には他にもセキュアなアーキテクチャであるかチェックする(設計)、インシデントが発生していないかログをチェックする(運用監視)なども含める場合もありますが、今回は設定値という定量的に確認することができる項目を活用したセキュリティチェックをスコープとします。
このセキュリティチェックのスコープは定量的であるため、知識があまりない状態でも簡単に利用・評価できる利点があります。つまり初心者でも始めやすいです。
ちなみにセキュアなアーキテクチャであるか、という点についてはAWSの設計のベストプラクティス集であるWell-Architectedフレームワークを活用するといいでしょう。AWS上でワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティスについて説明されているため、設計の初期段階から活用することが推奨されますが初期にドキュメントを読むとハードルが高く感じられるかもしれません。噛めば噛むほどじわじわ浸透していくものだと思いますので、継続的に読み続けて身につけていきましょう。
2020年7月に新しいバージョンがリリースされていますので、最新版をキャッチアップできていない方は下記も参照してみてはいかがでしょうか？
2つのセキュリティチェックの目的
AWS環境のセキュリティチェックを行いたい場合、大きく以下の2つの目的があると思います。
- 構築したAWS環境で適切な設定がされているか不安なため単発でチェックしたい
- セキュアに構築した環境がセキュアに維持されていることを定常的にチェックしたい
つまり1回チェックできればいいのか、維持管理がしたいのか、という違いがあります。
が、今回紹介する方法はどちらも包括します。同じ方法で解決できますので安心してください。
セキュリティチェックの手法
具体的なセキュリティチェックの手法について見ていきます。
セキュリティチェックを行うAWSサービス
定量的に設定値をチェックするAWS環境のセキュリティチェックを行う場合、AWSサービスとしては以下のサービスを利用することが可能です。
- AWS Config Rules
- AWS Security Hub
- AWS Config Conformance Packs
それぞれの特徴と、どのようなチェックができるかを説明します。
- AWS Config Rules
- AWSの各種リソースの設定やその変更を管理するAWS Configサービスの1機能
- 各種リソースの設定がConfig Rulesで定めた値であるかをチェックする
- チェックに違反すると通知したり修正したりできる
- ルールはAWSが提供するマネージドルールと利用者がLambdaで作成できるカスタムルールがある
- 2020/10/08現在で162個のマネージドルールが存在していて、どんどん増えている
- AWS Security Hub
- 2018年のre:Inventで発表されたセキュリティのコンプライアンスとステータスを一括で管理できるサービス
- コンプライアンス基準(スタンダード)に沿ったセキュリティチェックと、セキュリティイベント集約の大きく2つの機能がある
- チェックできるコンプライアンス基準は以下の3つ
- CIS AWS Foundations Benchmark
- PCI DSS v3.2.1
- AWS Foundational セキュリティベストプラクティス
- コンプライアンス基準のチェック有効化はボタン一発
- チェックの実際の仕組みはConfig Rulesのルールがセットになっている
- AWS Config Conformance Packs
- 2019年に追加されたAWS Configの機能の1つ
- 複数のConfig Rulesをまとめたサンプルテンプレートを多数公開している
- CISやPCI DSSに始まり、HIPAA / NIST CSF / FedRAMPのようなコンプライアンス基準もカバー
- S3やDynamoDB、IAMなどサービス毎のサンプルもある
- 実態はConfig RulesをCloudFormationテンプレートとしてまとめている
- サンプルテンプレートを活用して任意のルールを組み合わせて管理することが可能
少し細かい話をしましたが、簡単に言うとConfig Rulesはセキュリティチェックをする大元の機能で、Security HubやConformance Packsはこれを内包した機能です。Security Hubは展開が簡単ですがルールをアレンジできません。Conformance Packsはテンプレートがいっぱいあってかつ自分なりにアレンジできますがCloudFormationの知識が必要であったり自分でテンプレートを編集できる必要があります。
どちらも長短あるので使い分けていく感じになります。
セキュリティチェックのための基準
先程から何度か上がっているセキュリティチェックに使われる基準があります。以下のようなものになります。
- CIS AWS Foundations Benchmark
- PCI DSS v3.2.1
- HIPAA
- などなど
AWSのセキュリティチェックについて調べると、一番良く出てくるのはCIS AWS Foundations Benchmarkだと思います。
CISとは「米国政府機関と、企業、学術機関などが協力して、インターネット・セキュリティ標準化に取り組む団体」であり、例えばRHELやCentOSなどOSのセキュリティやApache HTTP ServerやBINDなどソフトウェアのセキュリティなどの設定値のベンチマークも作成しています。その中にAWSも含まれています。
このCIS AWS Foundations Benchmarkは2016年に発表されており、かなり早い段階から第三者の視点で定量的にチェックができる基準としてAWS利用者に活用されてきました。大きく以下の4つのカテゴリで49個のセキュリティチェックがあります。
- IAM
- Logging
- Monitoring
- Networking
AWSがSecurity HubやConformance Packsをリリースするずっと前から存在しており、そのためAWSのセキュリティチェックといえばこれ！という一定の評価を獲得しています。
リリース時の以下の解説ブログを見ていただくと、当時の喜びやチェックの具体的な中身について理解できると思います。
実はクラスメソッドでもこのCIS AWS Foundations Benchmarkをチェックするためのサービスを提供していました。
insightwatchというセキュリティチェックツールでAWSアカウントを無料でチェックしてレポーティングできるサービスです。2018年5月にリリースされました。こちらもSecurity HubやConformance Packsよりも前から存在していました。簡単に・無料で・定量的なチェックを行いわかりやすいレポートを出力できる控えめに言って最高なサービスでした。僕自身も様々なお客様の環境チェックに利用していました。以下のような感じです。
残念ながら先日サービス提供終了のアナウンスをしました。2021年3月31日17時（日本時間）をもって終了となっています。
いろんな背景があり私もすべて知っているわけではないですが、やはりひとつ大きな要因としては先程まで上げていたSecurity HubやConformance PacksなどのAWS純正サービスの成長があります。これらのサービスが良く成熟してきているので、insightwatchは勇退できるのだと思います。
今までありがとうinsightwatch！
……さて、話が少し横にそれてしまいましたが、歴史的に早くから存在していたCIS AWS Foundations Benchmarkが引き合いに出される事が多いセキュリティチェックの基準ですが、その他にもPCI DSSやHIPAAなど各種コンプライアンス基準に対応するためのルールセットが提供されています。これらの基準を満たす必要があるシステムを扱う場合には、最初からそれらを使うといいでしょう。注意点として、用意されているルールセットを活用すればコンプライアンス基準に完全に準拠できるわけではありません。各種コンプライアンス基準は定量的なチェックだけでは測ることができない要素を多分に含んでおり、最終的には監査員の判断に委ねられるためです。
今回は、そのような明確な要件がない場合にどうするのがいいのか？というところを考えてみたいと思います。
どの手法が"最強"なのか？
おまたせしました。ようやく本題ですね。ここまでの内容を箇条書きで整理します。
- 定量的に評価できるAWSの設定値をセキュリティチェックとして扱う
- AWSサービスとしてSecurity HubとConformance Packsがセキュリティチェックとしてよく使われる
- チェック基準はCISやPCIなどいろいろある、場合によりカスタマイズできる
つまり利用できるサービスや基準・ルールがいっぱいあるのでどれから手を付けたらいいのかわからない、というのがセキュリティチェックを始める際の一般的な課題なのです。
その課題を解決するための手法は…
ずばり、Security Hubを利用してAWS Foundational セキュリティベストプラクティス(AWS 基礎セキュリティのベストプラクティス)を有効化するのが最強です！
ここまでCISめっちゃ説明していて使わないんかーい！と思った方もいるかもしれませんｗ
順に説明していきます。
Security HubかConformance Packsか
まずこの2つのどちらを利用するのかですが、現状では圧倒的にSecurity Hubが使いやすいです。以下メリットを書いていきます。
- 基準の有効化がボタン一発で簡単
- 各ルールの説明がコンソール上でも丁寧で、必要なければコンソールから無効化できる
- 各リソース個別のステータスを管理でき、例外登録が非常に簡単にできる
- Config Rulesについて深く理解しなくても使える
様々な場面でConformance Packsよりも簡単に利用できるのがいいところです。
逆にConformance PacksにあってSecurity Hubには無いメリットはルールのカスタマイズ性ですが、カスタマイズにはかなりの苦しみを伴います。
初めてセキュリティチェックを行い場合も、ある程度定常的に回したい場合もSecurity Hubに軍配があがります。特にConformance Packsで例外登録ができない(手段はなくはないがつらい)のは致命的です。
どの基準を利用するか
AWS Foundational セキュリティベストプラクティスを使いましょう！
この基準が何かというと、2020年4月というかなり最近リリースされたAWSが定義したセキュリティチェックリストです。これまでなにかの外部団体の基準を参照して作られていたルールばかりでしたが、初めてAWSとしてまとめたルールとなります。NISTサイバーセキュリティフレームワーク(CSF)を参考にした分類になっています。詳細は以下のリリース時のブログを参照してください。
なぜCISではなくAWS Foundationalセキュリティベストプラクティスなのかというと、CISは古くこちらは新しいからです。非常に単純ですね。
もう少し具体的に見ていきましょう。
CISでチェックするリソース一覧は以下のようになっています。
- AWS CloudTrail trail
- Amazon EC2 security group
- Amazon EC2 VPC
- IAM policy
- IAM user
- AWS KMS key
- S3 bucket
一方でAWS Foundationalセキュリティベストプラクティスでチェックするリソースは以下のようになっています。
- ACM Certificate
- Amazon EBS volume
- Application Load Balancer
- Amazon EFS file system
- CloudFront distribution
- CloudTrail trail
- CodeBuild project
- Amazon EC2 instance
- Amazon EC2 security group
- Amazon EC2 volume
- Elastic Load Balancing load balancer
- Elasticsearch domain
- GuardDuty detector
- IAM group
- IAM policy
- IAM role
- IAM user
- AWS KMS key
- Lambda function
- Amazon RDS DB cluster snapshot
- Amazon RDS DB instance
- Amazon RDS snapshot
- Amazon S3 Block Public Access
- S3 bucket
- Systems Manager managed instance inventory
- Systems Manager patch compliance
- Subnet
一目瞭然ですね。カバーするリソースの種類が段違いなのです。CISの7種類に対して27種類あります。
最近では当たり前になったGuardDutyやS3パブリックアクセスブロックなどのセキュリティ機能についてもCISは対応できていません。これも古いチェックであるがゆえです。
また、私がここでCISをオススメしない最大の理由は、CISの内容のうち3. Monitoringの項目が運用上活用されないセキュリティアラートをたくさん発生させることにあります。
- MonitoringではCloudTrailのログ(AWS APIの実行ログ)をCloudWatch Logs(ログ保存・検索機能)に流すように設定した後、ネットワークやIAMの変更などが発生したらすべて通知する設定を導入することが定められています。本番環境ですべての設定はめったに発生しない、というような場合にはあまり困りませんが、それ以外の場合は大いに困るチェックで大体はオオカミ少年になります。
これ以外の主要なCISのチェック項目はAWS Foundational セキュリティベストプラクティスでももちろん含まれていることから、今CISを利用するメリットは少ないです。
最強の手法まとめ
というわけで改めてですが
Security Hubを利用してAWS Foundational セキュリティベストプラクティス(AWS 基礎セキュリティのベストプラクティス)を有効化するのが最強です！(私が思うに)
以下のような場合には特にこの手法を強く推奨します。
- とりあえず作ったAWS環境のセキュリティが不安だからチェックしたい
- 継続的にAWS環境のセキュリティを維持管理することを始めてみたい
- insightwatchの終了に伴い代替え手法を検討したい
私は現状、とりあえずAWS環境のセキュリティチェックをしたいなら間違いなく上記をオススメしますが、もちろん異論は認めます。
例えば運用負荷がめちゃくちゃ高くなってもすべての変更管理をCISに沿って行いたい場合にはCISを全体に徹底してもいいですし、より柔軟に自分たちのやりたい運用に合わせてカスタマイズしたい場合にはConformance PacksやConfig Rulesを直接利用する方法を、AWS Organizationsと組み合わせて全体に展開する(以下参考ブログ)などの手法もあります。
あるいは前述の通りPCI DSSなど明確に対応すべき基準がある場合はそれを使えばいいです。
しかしながらどれも具体的に何がやりたいかが見えて、運用できる自身がある段階で採用すべきものです。
それが判断できる頃には、私が思う最強の手法ではなく、自分が思う最強の方法を目指してください。
設定方法
というわけで最強の手法を設定していきましょう。簡単なので一緒にやってみるのもいいと思います。
まずAWSマネジメントコンソールにログインしてSecurity Hubのページを開きます。「Security Hubに移動」を押します。
有効化画面ではAWS Foundational セキュリティベストプラクティス(AWS 基礎セキュリティのベストプラクティス)のみチェックを入れて有効化ボタンを押します。
「セキュリティ基準」を開くとAWS Foundational セキュリティベストプラクティスが有効化されているか、有効化している最中です。最中の場合は数分待ちましょう。スコアが出てきて詳細を見れるようになります。
この中のFailedをチェックしていけばOKです！ちなみに有効化したばかりだとすぐにチェックできない項目があるため、1日くらい立ってから見に来ると各チェックが完了しているので、そのタイミングで評価することをオススメします。
設定は上記で終わりで非常に簡単です。
チェックできる項目
AWS Foundational セキュリティベストプラクティスでは現在以下の項目がチェックできます。52項目です。いっぱいあるのでさらーっと流し見するのがいいと思います。
- [ACM.1]インポートされたACM証明書は、指定された期間後に更新する必要があります
- [AutoScaling.1]ロードバランサーに関連付けられているAutoScalingグループは、ロードバランサーのヘルスチェックを使用する必要があります
- [CloudTrail.1] CloudTrailを有効にして、少なくとも1つのマルチリージョントレイルで構成する必要があります
- [CloudTrail.2] CloudTrailでは、保存時の暗号化を有効にする必要があります
- [CodeBuild.1] CodeBuildGitHubまたはBitbucketソースリポジトリのURLはOAuthを使用する必要があります
- [CodeBuild.2] CodeBuildプロジェクト環境変数にクリアテキストの資格情報を含めることはできません
- [Config.1] AWSConfigを有効にする必要があります
- [DMS.1]データベース移行サービスのレプリケーションインスタンスは公開しないでください
- [EC2.1] Amazon EBSスナップショットは公開しないでください。これは、誰でも復元できるかどうかによって決まります。
- [EC2.2] VPCのデフォルトのセキュリティグループは、インバウンドトラフィックとアウトバウンドトラフィックを許可しないようにする必要があります
- [EC2.3]接続されたEBSボリュームは保存時に暗号化する必要があります
- [EC2.4]停止したEC2インスタンスは、指定した期間の後に削除する必要があります
- [EC2.6] VPCフローロギングをすべてのVPCで有効にする必要があります
- [EC2.7] EBSのデフォルトの暗号化を有効にする必要があります
- [EC2.8] EC2インスタンスはIMDSv2を使用する必要があります
- [EFS.1] Amazon EFSは、AWSKMSを使用して保存されているファイルデータを暗号化するように設定する必要があります
- [ELBv2.1]アプリケーションロードバランサーは、すべてのHTTPリクエストをHTTPSにリダイレクトするように構成する必要があります
- [EMR.1] AmazonEMRクラスターマスターノードにパブリックIPアドレスを設定しないでください
- [ES.1] Elasticsearchドメインでは、保存時の暗号化を有効にする必要があります
- [GuardDuty.1] GuardDutyを有効にする必要があります
- [IAM.1] IAMポリシーでは、完全な「*」管理者権限を許可しないでください
- [IAM.2] IAMユーザーはIAMポリシーを添付しないでください
- [IAM.3] IAMユーザーのアクセスキーは90日以内にローテーションする必要があります
- [IAM.4] IAMルートユーザーアクセスキーは存在しないはずです
- [IAM.5]コンソールパスワードを持つすべてのIAMユーザーに対してMFAを有効にする必要があります
- [IAM.6] rootユーザーに対してハードウェアMFAを有効にする必要があります
- [IAM.7] IAMユーザーのパスワードポリシーには強力な構成が必要です
- [IAM.8]未使用のIAMユーザー認証情報を削除する必要があります
- [KMS.1] IAMの顧客管理ポリシーは、すべてのKMSキーで復号化アクションを許可するべきではありません
- [KMS.2] IAMプリンシパルには、すべてのKMSキーで復号化アクションを許可するIAMインラインポリシーを含めるべきではありません
- [Lambda.1] Lambda関数は、他のアカウントによるパブリックアクセスを禁止する必要があります
- [Lambda.2] Lambda関数は最新のランタイムを使用する必要があります
- [RDS.1] RDSスナップショットはプライベートにする必要があります
- [RDS.2] RDS DBインスタンスは、PubliclyAccessible構成によって決定されるパブリックアクセスを禁止する必要があります
- [RDS.3] RDS DBインスタンスでは、保存時の暗号化を有効にする必要があります
- [RDS.4] RDSクラスタースナップショットとデータベーススナップショットは保存時に暗号化する必要があります
- [RDS.5] RDSDBインスタンスは複数のアベイラビリティーゾーンで構成する必要があります
- [RDS.6] RDSDBインスタンスとクラスターに対して拡張モニタリングを構成する必要があります
- [RDS.7] RDSクラスターで削除保護を有効にする必要があります
- [RDS.8] RDSDBインスタンスで削除保護を有効にする必要があります
- [S3.1] S3ブロックパブリックアクセス設定を有効にする必要があります
- [S3.2] S3バケットはパブリック読み取りアクセスを禁止する必要があります
- [S3.3] S3バケットはパブリック書き込みアクセスを禁止する必要があります
- [S3.4] S3バケットでサーバー側の暗号化を有効にする必要があります
- [S3.5] S3バケットでは、Secure SocketLayerを使用するためのリクエストが必要です
- [S3.6]バケットポリシーで他のAWSアカウントに付与されるAmazonS3パーミッションを制限する必要があります
- [SageMaker.1] SageMakerノートブックインスタンスはインターネットに直接アクセスできないようにする必要があります
- [SecretsManager.1]シークレットマネージャーのシークレットでは、自動ローテーションを有効にする必要があります
- [SecretsManager.2]自動ローテーションで構成されたSecretsManagerシークレットは正常にローテーションする必要があります
- [SSM.1] EC2インスタンスはAWSSystemsManagerで管理する必要があります
- [SSM.2] Systems Managerによって管理されるすべてのEC2インスタンスは、パッチ適用要件に準拠している必要があります
- [SSM.3] Systems Managerによって管理されるインスタンスは、COMPLIANTのアソシエーションコンプライアンスステータスを持っている必要があります
元ソースはこちら。それぞれの項目についての細かい解説は今回は置いておきます。前述した以下のブログで細かく解説していますので気になる方はこちらをチェック！
確認・修正方法
チェックが終わった後は実際に違反しているリソースを確認して修正していきます。
今回は「[EC2.2] VPCのデフォルトのセキュリティグループは、インバウンドトラフィックとアウトバウンドトラフィックを許可しないようにする必要があります」の違反があったので修正してみます。まずルールの詳細画面に入ります。違反しているリソースがFAILEDのステータスで表示されています。各ルールに違反したリソースを修復する方法はユーザーガイドにまとまっていて、そのリンクが概要のところに「修復手順」として置いてあるのでこれを開きます。
Remediation(修復)の方法が具体的にユーザーガイドにまとまっています。EC2.2のルールはデフォルトセキュリティグループのinbound/outboundルールをすべて削除しなさいというものなので、それを実施していきます。
Security Hubのルールの画面に戻り、違反しているリソースのリソース名をクリックして、出てきたフキダシから実際のリソースのページに飛ぶことが可能です。
今回はユーザーガイドに沿って、inbound/outboundルールを削除していきます。
変更後、2-3分でEC2.2のステータスが成功となりました。該当リソースのステータスもPASSEDに変わっています。
チューニング
すべての項目に対応していってもいいですが、やっぱりいろんなチェック項目があるので少しはチューニングしたほうがいいです。
といっても、Security Hubのチューニングは非常に簡単で、例外リソースを登録することと不要なルールを無効化することの2つです。
例外リソースですが、このリソースだけは基準を満たしていなくても無視する、ということは運用上よくありますよね？その登録です。
以下はLambdaのランタイムが最新ではないというルールに違反しているリソースを例外登録する例です。最新ではなくても使い続けることができるので、必ずしも対応しなければいけないものでもないと思います。このあたりの判断は環境に合わせてやっていきましょう。FAILEDとなっているリソースを選択して「ワークフローのステータス」から「抑制済み」を選択します。
選択したリソースが抑制済みとなり、ルール全体としてはステータスが成功になりました。
続いて不要なルールの無効化です。AWS Foundational セキュリティベストプラクティスでは(CISと比べれば)かなり現実的なルールが多いですが、それでも無効化を検討したほうがいいルールがいくつかあります。
私の推奨する無効化したほうが良いルールと理由を置いておきます。
- [EC2.8] EC2インスタンスはIMDSv2を使用する必要があります
- IMDS(インスタンスメタデータサービス)v2はセキュリティを強化した機能です
- SSRFなどの攻撃に対して一定の耐性があるなどメリットがあります
- しかし通常のEC2起動プロセスなどでもIMDSを使っており、それがIMDSv2に対応していないことも多いため強制するにはかなりハードルが高いルールです
- [IAM.6] rootユーザーに対してハードウェアMFAを有効にする必要があります
- ソフトウェアMFAで運用することも多いためその場合には外します
- [S3.1] S3ブロックパブリックアクセス設定を有効にする必要があります
- アカウント全体でのパブリックアクセスブロックが必要とされます
- 公開するS3バケットが一切ないアカウントでは活用してもいいですが、そうではない場合は無効化します
- [S3.5] S3バケットでは、Secure SocketLayerを使用するためのリクエストが必要です
- S3静的ホスティングを行う場合に活用したほうが良いルールです
- ただし、存在するすべてのS3バケットに該当の設定を求めるため、公開しないS3を多く管理している場合運用が煩雑になるため無効化も検討します
無効化の方法も紹介します。ルールの詳細画面の右上に「無効化」ボタンがありますのでこれを押します。
無効化する理由を記入します。
ステータスが無効となり、無効化した日付と理由が表示されました。
その他の要素
他にもセキュリティチェックを行っていく上で役に立つ情報をいくつかまとめておきます。
- 違反があった項目を通知する(普段からダッシュボードを見に行かない場合には設定を推奨)
- Security Hubで違反した項目を自動修復するソリューション(まだCISしか対応していませんが)
- AWSさんのSecurity HubのDeep Diveセッション(マルチアカウントの管理方法などもあり)
- Conformance PacksのNIST CSFを活用する場合の使い方
- Conformance PacksをOrganizationsを利用してマルチアカウントに展開する
- Security Hubによるセキュリティチェックの料金
- セキュリティチェック(中身はConfig Rules)の料金はSecurity Hubの料金として計算される
- チェック/アカウント/リージョン/月あたり最初の 10 万回までは0.0010USD/チェック
- 例えばチェックが1,000回走ると1.00 USDとなる
- 詳細はこちら
- 30 日間のトライアル期間があり、「設定 -> 使用」画面で利用状況が確認できるため、まず使ってみて実際のチェック数を確認してみるといい
まとめ
AWS環境で最強のセキュリティチェック方法についてまとめました。
一通りセキュリティチェックを始めたり運用するのに必要な情報がまとめられたと思います。
Conformance PacksやConfig Rulesの直接利用もいいですが、もし初めてならまずSecurity Hubを使ってみてはいかがでしょうか？
そしてなれてきたら、より環境に最適化した方法を検討してみてください！
